<HTML>
  <HEAD>
    <TITLE>Certificate Access</TITLE>
    <!-- Changed by: Roger Riggs - Sun Microsystems Inc, 10-Mar-2002 -->
    <!-- Changed by: Gary Adams - SMI Software Development, 11-Jul-2002 -->
  </HEAD>
  <BODY>
    Certificates are used to authenticate information for secure
    Connections.
    The <CODE>Certificate</CODE> interface provides to the
    application information about the origin and type of the certificate.
    The <CODE>CertificateException</CODE> provides information about
    failures that may occur while verifying or using certificates.
    <P>
      The MIDP X.509 Certificate Profile below defines the format and
      usage of certificates.  X.509 Certificates MUST be supported.
      Other certificate formats MAY be supported.  The implementation
      MAY store only the essential information from certificates.
      Internally, the fields of the certificate MAY be stored in any
      format that is suitable for the implementation.
    </P>

    <H3>References</H3>
    <P>MIDP 2.0 devices are expected to operate using standard Internet
      and wireless protocols and techniques for transport and security. The
      current mechanisms for securing Internet content is based
      on existing Internet standards for public key cryptography:</P>
    <UL>
      <LI><A HREF="http://www.ietf.org/rfc/rfc2437">[RFC2437] - PKCS
	    #1 RSA Encryption Version 2.0</A>
      </LI>
      <LI><A HREF="http://www.ietf.org/rfc/rfc2459">[RFC2459] - Internet
	    X.509 Public Key Infrastructure</A>
      </LI>
      <LI> <A
      HREF="http://www.wapforum.org/what/technical.htm">[WAPCERT] -
	  WAP-211-WAPCert-20010522-a -
	  WAP Certificate Profile Specification</A>
      </LI>
    </UL>

    <H2><A NAME=profile>MIDP X.509 Certificate Profile</A></H2>

    <P>WAP-211-WAPCert-20010522-a [WAPCert] which is based on 
      RFC2459 Internet X.509 Public Key
      Infrastructure Certificate and CRL Profile [RFC2459].</P>

    <P>Devices MUST conform to all mandatory requirements in
      [WAPCert] and SHOULD conform to all optional requirements in
      [WAPCert] except those requirements in excluded sections listed
      below.  Mandatory and optional requirements are listed in Appendix
      C of [WAPCert]. 
      Additional requirements, ON TOP of those listed in [WAPCert]
      are given below.
    </P>

    <UL>
      <LI>Excluding [WAPCert] Section 6.2, User Certificates for
	Authentication
      </LI>
      <LI>Excluding [WAPCert] Section 6.3, User Certificates for
	Digital Signatures
      </LI>
    </UL>


    <P>RFC2459 contains sections which are not relevant to
      implementations of this specification. The WAP Certificate
      Profile does not mention these functions. The sections to be
      excluded are: 
    </P>
    <UL>
      <LI>Exclude the requirements from Paragraphs 4 of
	Section 4.2 - Standard Certificate Extensions. A conforming
	implementation of this specification does not need to recognize
	extensions that must or may be critical including certificate
	policies, name constraints, and policy constraints.
      </LI>

      <LI>Exclude RFC2459 Section 6.2 Extending Path Validation.
	Support for Policy Certificate Authority or policy attributes
	is not required.
      </LI>
    </UL>


    <H3>Certificate Extensions</H3>
    <P>
      A version 1 X.509 certificate MUST be considered equivalent to a
      version 3 certificate with no extensions.
      At a minimum, a device conforming to this profile MUST
      recognize key usage (see RFC2459 sec. 4.2.1.3),
      basic constraints (see RFC2459 sec. 4.2.1.10).
    </P>
    <P>
      Although a conforming device may not recognize the authority and subject
      key identifier (see RFC2459 sec. 4.2.1.1 and 4.2.1.2) extensions it MUST
      support certificate authorities that sign certificates using the same
      distinguished name but using multiple public keys.
    </P>

    <P>Implementations MUST be able to process certificates with
      unknown distinguished name attributes.</P>

    <P>Implementations MUST be able to process certificates with
      unknown, non-critical certificate extensions.</P>

    <P>The <CODE>serialNumber</CODE> attribute defined by [WAPCert]
      must be recognized in distinguished names for Issuer and Subject.</P>

    <H3>Certificate Size</H3>
    <P>Devices must be able to process certificates that are not
      self-signed root CA certificates of size up to at least 1500
      bytes.</P>

    <H3>Algorithm Support</H3>
    <P>A device MUST support the RSA signature algorithm with the
      SHA-1 hash function <CODE>sha1WithRSAEncryption</CODE>
      as defined by PKCS #1 [RFC2437].
      Devices that support these algorithms MUST be capable of
      verifying signatures made with RSA keys of length up to and
      including 2048 bits.
    </P>

    <P>Devices SHOULD support signature algorithms
      <CODE>md2WithRSAEncryption</CODE> and
      <CODE>md5WithRSAEncryption</CODE> as defined in [RFC2437].
      Devices that support these algorithms MUST be capable of
      verifying signatures made with RSA keys of length up to and
      including 2048 bits.
    </P>

    <H3>Certificate Processing for HTTPS</H3>
    <P>Devices MUST recognize the extended key usage extension defined
      of RFC2818 if it
      is present and is marked critical and when present MUST verify that
      the extension contains the <CODE>id-kp-serverAuth</CODE> object
      identifier (see RFC2459 sec. 4.2.1.13).</P>

    <P>SSL and TLS allow the web server to include the redundant root
       certificate in the server certificate message. In practice this
       certificate may not have the basic constraint extension (it is
       most likely a version 1 certificate), a device MUST ignore the
       redundant certificate in this case. Web servers SHOULD NOT
       include a self-signed root CA in a certificate chain.</P>

   @since MIDP 2.0

  </BODY>
</HTML>
